feat(unstable-v2): add background work to v2 - #2738

…FD (#2743)

* docs(schema): restore the v1 meaning of Implementation.title and the tool-call intro

The plain-language pass (#2730) changed two v1 passages beyond wording:

- `Implementation.title` said it "should be readable by people", which adds
  a should-statement to the stable v1 spec and schema. Restore the v1.14.0
  meaning ("optimized to be human-readable and easily understood") without
  the em dash. The v2 copy uses the same text.
- The v1 tool-calls intro said Agents may use Client capabilities "while
  running a tool call", which reads as a new timing limit. Drop the temporal
  clause and keep the original "or".

Co-Authored-By: Claude <noreply@anthropic.com>

* docs(protocol): align v2 session/cancel text with the background-work rules

#2738 narrowed `session/cancel` so listed background work keeps running and
its permission requests stay open, but several v2 passages still stated the
old rule. Update them in the stable and draft pages and the v2 schema:

- prompt-lifecycle: add the missing "or" in the announce-before-listing
  rule (stable only, the draft already had it), scope "stop all tool call
  invocations" to the cancelled foreground work, put the `-32800` rule next
  to the prompts it covers, and state that a `subject` the Client does not
  recognize, such as a custom subject type, is answered with `cancelled`.
- tool-calls, cancellation, migration: answer pending permission requests
  for the cancelled foreground work, not every request in the session.
- Schema: `RequestPermissionOutcome::Cancelled`, the
  `session/request_permission` request and the `session/cancel`
  notification descriptions now state the narrowed rule and the custom
  subject case.

Co-Authored-By: Claude <noreply@anthropic.com>

* docs(unstable): reconcile session/status, auth/status and session/set_title with their RFDs

- session/status: keep `-32002` for sessions the Agent does not know, and
  state the RFD's exception in the schema, the draft error pages and the
  RFD's own error rule: an Agent that cannot cheaply tell a saved session
  from an unknown one may return `saved`, and the later resume or load gets
  `-32002`.
- auth/status: add it to the draft v2 list of requests that do not fail
  with `auth_required`, and put the RFD's MUST NOT in the schema.
- session/set_title: refusing a session the Agent cannot safely update
  returns `-32602`, as an explicit exception to retitling any listed
  session, in the schema, the draft error pages and the RFD.

Co-Authored-By: Claude <noreply@anthropic.com>

* docs(rfd): resolve proxy-chains ambiguities and match the reference conductor

Define, in the proxy-chains RFD and the proxy schema descriptions:

- Errors the conductor returns itself (before initialization, failed
  chain start, `proxy/initialize` from outside, misplaced `proxy/successor`,
  malformed envelopes, a component that exited), separate from the
  pass-through rule for wrapped results.
- Hop-local cancellation: `$/cancel_request` names a request on its own
  connection, is never forwarded, and each hop re-issues it.
- Envelope `_meta` is hop-local and not copied into the unwrapped message.
- Version selection along the chain, the proxy's obligation to forward
  `initialize` before answering, the proxy/initialize result built from the
  successor's (same `protocolVersion`), and repeated `proxy/initialize`.
- "Unchanged" results and errors mean the same JSON value.
- Wrapped `params` is an object, an array, or `null`.
- Forwarding of unknown requests and notifications and where `-32601`
  comes from.

Also link version negotiation for v1 and v2, replace the old
`sacp-conductor` name, drop crash-handling claims the reference conductor
does not implement, and add a revision-history entry.

Co-Authored-By: Claude <noreply@anthropic.com>

* docs(unstable): drop the saved-for-unknown and retitle-refusal exceptions

Co-Authored-By: Claude <noreply@anthropic.com>

* docs(protocol): let the Agent cancel permission requests on session/cancel in v2

The Agent knows which work each permission request belongs to, so on
session/cancel it stops waiting for the cancelled work's requests and
cancels them with $/cancel_request, as it already does for elicitations.
Clients MAY answer them early. session/close cancels every pending
permission request the same way. This removes the subject-based rules
for which requests the Client answers.

Co-Authored-By: Claude <noreply@anthropic.com>

---------

Co-authored-by: Claude <noreply@anthropic.com>